home *** CD-ROM | disk | FTP | other *** search
/ Almathera Ten Pack 3: CDPD 3 / Almathera Ten on Ten - Disc 3: CDPD3.iso / scope / 051-075 / scopedisk52 / tutor / c1 < prev    next >
Text File  |  1995-03-18  |  9KB  |  259 lines
  1. Commands in this section are:
  2.  
  3. CD
  4. PATH
  5. ASSIGN
  6. ECHO
  7. TYPE
  8.  
  9. ________________________________________________________________________________
  10.  
  11. CD
  12.  
  13. displays or sets the current directory
  14.  
  15. We've used this command already and talked a little bit about the
  16. whole concept, so it shouldn't be necessary to go much further into it.
  17.  
  18. ________________________________________________________________________________
  19.  
  20. PATH
  21.  
  22. sets, resets, adds to the search path AmigaDOS follows to find
  23. commands typed in at the CLI prompt
  24.  
  25. Once again, don't confuse PATHNAME with PATH! But they are similar.
  26. A PATHNAME is the route AmigaDOS takes to get to a specific file. The PATH is
  27. the route along  which AmigaDOS looks for the command you want performed.
  28.  
  29. >> PATH
  30. Current Directory
  31. C:
  32.  
  33. You can make this path as circuitous as you wish. For instance, I have
  34. two directories full of commands on my workbench disk, one that's copied to
  35. RAM: upon startup  and  the  other  that  just  stays  on  the  disk. In my
  36. startup-sequence I have a line:
  37.  
  38. PATH ADD disk_resident_directory
  39.  
  40. this puts the disk resident directory in  the search path since I assign C:
  41. to the directory in RAM:.
  42.  
  43. To change the search path back to the original settings, one would
  44. type:
  45. PATH RESET
  46.  
  47. ________________________________________________________________________________
  48.  
  49. ASSIGN
  50.  
  51.     gives a "device" name to directory.
  52.  
  53.     Assignments are simply giving device  names  (they  end in ":") to any
  54. existing directory. This directory can be as far down the PATHNAME as you
  55. desire. When  the  Amiga  starts  up,  it  automatically  makes certain
  56. assignments.
  57.  
  58. >> ASSIGN /* or ASSIGN LIST */
  59. /* hereafter would be a wealth of information.  First, the volumes that are
  60. in use by the system. Then  the  directories  that  have active assignments
  61. made to them. And finally, the actual physical  devices that are recognized
  62. by the OS at the time. */
  63.  
  64. /* assuming a single drive system, it would look something like this: */
  65. Volumes:
  66. Tutor [mounted]
  67. RAM Disk [mounted]
  68.  
  69. Directories:
  70. C         RAM:C               /* this is where COMMANDs live */
  71. DEVS      Tutor:devs          /* DEVICES like the "printer.device" */
  72. FONTS     Tutor:fonts         /* FONTS are the displayed characters */
  73. L         Tutor:l             /* various "handlers" */
  74. LIBS      Tutor:libs          /* various "library" files */
  75. S         Tutor:s             /* where BATCHFILEs like to call home */
  76. SYS       Tutor:              /* the "system" disk or the one "booted" */
  77.  
  78. Devices:
  79. CON DF0 PAR PRT RAM
  80. SER
  81.  
  82. Notice  everything   is   assigned   to   Tutor:  except  C:.  In  the
  83. startup-sequence I have the whole  Tutor:c  directory  copied to RAM: (this
  84. bypasses the step mentioned above and speeds  up the operation) and then C:
  85. is assigned to RAM:C.
  86. /* a word of caution, using the shotgun  approach to putting a C:
  87. in RAM: is all well and good if you have more RAM: than you know what to do
  88. with, but it's better to conserve a little and only put the most often used
  89. stuff there */
  90.  
  91. You can give any directory a device name  with the ASSIGN command. For
  92. example:
  93.  
  94. >> DIR df0:devs/printers
  95. generic
  96. >> ASSIGN foo: df0:devs/printers
  97. >> DIR foo:
  98. generic
  99.  
  100.     Why mess with it at all? As you start getting the hang of this CLI
  101. business, you'll start to realize.."If I have more commands in C:, I can do more
  102. things!!"
  103.     Well, an outofthebox workbench is pretty full. But a lot of it is simply
  104. junk you don't need or are things that can be stored elsewhere. For example,
  105. your fonts directory.
  106.     Fonts are great. They allow you all manner of freedom when doing certain
  107. things, but the only utility on your WB can utilizes them is the notepad.
  108.     Notepad is OK, but for a "working-type-down-in-the-trenches" WB, you
  109. don 't need it.
  110.     Alright, we can get rid of both of these /* and we will, but later */
  111. and free up some disk space that can ultimately be put to better use.
  112.     
  113.     Now, let's consider a situation in which we'd want to use ASSIGN.
  114.  
  115.     We have a utility program that uses fonts. And it is on it's own disk
  116. with it's own fonts directory, with a DIFFERENT set of fonts than are found on
  117. the workbench. This program might be a desktop publisher of one of the
  118. "painting" programs, but usually, when told to "load fonts", they'll go to
  119. "fonts:" /* the logical device FONTS */ rather than to the DISKNAME:fonts
  120. directory. Do you see the difference?
  121.     Now, whether we've moved OUR fonts directory off of the WB disk or
  122. not, the utility program still won't be able to load the fonts that are on the
  123. disk with it.
  124.     Here's where the ASSIGN command would come into play.
  125.     Before we start the program, we'd go to the CLI and type:
  126.  
  127. BS> ASSIGN fonts: DISKNAME:fonts
  128.  
  129.     Then when we made our "load fonts" instruction from within our program,
  130. we'd be sending it to the fonts directory of OUR chosing. Handling the situation
  131. like this, we could have any number of "fonts" directories set up and could
  132. tailor our approach to a certain task more efficiently.
  133.     The idea being that if it makes it easier for you, DO IT !!!
  134.  
  135.     Another situation where an ASSIGNed name might make things easier could
  136. be, you have a directory in a directory in a directory in a directory.
  137.         /* whew! */
  138. But, you wanted it that way and now you have to...oh, let's say COPY some of
  139.     those files elsewhere. Rather than having to type in:
  140.  
  141. BS> COPY diskname:directory/directory/directory/directory/filename destination:
  142.  
  143.     for each file you wanted to copy, if you:
  144.  
  145. BS> ASSIGN source: diskname:directory/directory/directory/directory
  146.  
  147.     you would:
  148.  
  149. BS> COPY source:filename destination:
  150.  
  151. and if you were faced with a destination pathname just as long, you could make a
  152. second assignment to it.
  153.  
  154.  
  155. Names are unASSIGNed thusly:
  156.  
  157. >> ASSIGN foo:
  158.  
  159. Now if you:
  160.  
  161. >> DIR foo:
  162.  
  163. you'll get a system request  that  you  insert  volume  "foo" in any
  164. drive. Just hit the  cancel  gadget  and  you'll  get  a message saying the
  165. system couldn't get  that  information  and  an  Error code 218 (device not
  166. mounted).
  167. Pretty neat, huh?
  168.  
  169. I mentioned, in passing, that C: and  S:  are the prefered "homes" for
  170. certain types of things. These two  directories  will be of more concern to
  171. us than any of the rest. As you fool around more, you'll both find commands
  172. that you want to add to your WB disk and begin writing batchfiles to handle
  173. mundane chores rather than typing lines repeatedly into the CLI. By design,
  174. AmigaDOS looks for commands in the  C: /* "C colon" NOT WB:c */ directory  and
  175. batchfiles in the S: /* "S colon" NOT WB:s */ directory.
  176.  
  177.     This doesn't mean you  can't  put them anywhere you want, but if
  178. you do you'll HAVE to use a complete PATHNAME so they can be found. This is
  179. really only a problem in that it requires more typing..this results in more
  180. work and greater potential for typos.
  181.  
  182.     If it seems I'm being lazy, why NOT let Amy do the legwork for you?
  183. Isn't that one of the reasons you bought it for in the first place?
  184.  
  185. ________________________________________________________________________________
  186.  
  187. ECHO
  188.     used in batchfiles to print a line of text to the screen.
  189.  
  190. >> ECHO "Greetings"
  191. Greetings
  192.  
  193. Notice that the text you want displayed must be enclosed in quotes
  194. and it can contain spaces.
  195.  
  196. >> ECHO "Are we getting anywhere?"
  197. Are we getting anywhere?
  198.  
  199. ________________________________________________________________________________
  200.  
  201. TYPE
  202. copies a file to the screen if no other place is specified.
  203.  
  204. >> TYPE examples/text
  205. /* a little message */
  206.  
  207. TYPE is useful if you want to print a message to the screen, perhaps
  208. in your startup-sequence, that's longer than a line or two, longer than is
  209. practical to do with seperate ECHO commands.
  210.  
  211.     The output from the TYPE command can be "redirected". We'll go into
  212. redirection more at a later time, but for now just try:
  213.  
  214. >> TYPE >ram:a examples/text
  215. >> TYPE ram:a
  216. /* the same little message */
  217.  
  218.     You noticed that when you typed in the first line, the drive light
  219. came on, but nothing appeared on the screen as it did in the first example.
  220. But when you typed in the second line, you got the same message as before.
  221.     You "redirected" the output of TYPE, created a file in ram: called
  222. "a", and stored TYPE's output in it. This output could, if you desire, be
  223. used in any way you can use a normal textfile. Have you made the connection
  224. that TYPE can do extra duty as both COPY and RENAME?
  225.  
  226. >> TYPE >ram:a c:dir
  227. >> ram:a
  228. /* the normal results of a DIR command */
  229.  
  230.  
  231.     TYPE will also type a binary file to the screen with non-fatal results
  232. as bizarre as any you're ever likely to see.
  233.  
  234. >> TYPE ram:a
  235. /* not as spectacular as some, but... */
  236.  
  237. You may have noticed that this provided neither useful information
  238. nor a "guru-ed" system.
  239.  
  240. So, should you inadvertently TYPE another one sometime, you'll at least know
  241. what it is.
  242.     However, sometimes it is advantageous to see what's in a binary file.
  243. That's what OPT H /* for hexadecimal */ is for. This will list the hexadecimal
  244. numbers on the left side of the screen and the ASCII equivalent on the right.
  245.  
  246. >> TYPE ram:a OPT H
  247. /* it still may not mean much, but you can take a closer look */
  248.  
  249.  
  250. ________________________________________________________________________________
  251.  
  252. Well that's it for this section. To move on to the next:
  253. Select the RETURN TO MAIN SCREEN option from the READER menu
  254. and type:
  255.  
  256. Reader CLI_tutorial.2
  257.  
  258. at the prompt in the upper window.
  259.